(no commit message)
authorgoglu6 <goglu6@web>
Fri, 17 Jan 2025 06:29:39 +0000 (06:29 +0000)
committeradmin <admin@branchable.com>
Fri, 17 Jan 2025 06:29:39 +0000 (06:29 +0000)
doc/bugs/Unlock_filter_seems_to_deadlock_for_huge_worktree.mdwn

index e6ba8e5bb1b1bfc03fd1de498904ad50a47bf896..e4d448f82868bbc0c7c3fe377fe4bd4ed22045ac 100644 (file)
@@ -5,11 +5,13 @@ I wanted to unlock all those files from that branch on a machine, so I tried to
 Sadly, the command do not seems to finish, ever.
 
 Executing the command with debug from a clone(to avoid interacting with the broken index from the first), it seems to deadlock after executing between 10000 and 20000 "thawing" processes when executing the filter-process logic over the files in the worktree.
-The problems seems to be reproducible with any repository with a lot of files in the worktree as far as I can tell, independant of file size.
+The problem seems to be reproducible with any repository with a lot of files in the worktree as far as I can tell, independant of file size.
 
-The infinite loop make higher-level commands like git annex sync also deadlock when checkout-ing the unlocked branch for any reason.
+The deadlock described makes higher-level commands like git annex sync also block indefinitely when checkout-ing the unlocked branch for any reason.
 Also, because the filtering is not completely applied, the index is pretty scrambled, its easier to clone the repo and move the annex than fix it, for me at least.
 
+I call the behavior "deadlock" due to the absence of outpout and low cpu usage on the process when in that state. This seems to indicate some kind of multiprocessing deadlock to me.
+
 ### What steps will reproduce the problem?
 
 Here is a minimum set of bash commands that generate the deadlock on my end: